Firewalls are network technologies that monitor and enforce rules, called policies, regarding data that passes to and from entities protected by, or “inside,” the firewalls. For example, a local are network (LAN) may be protected by a firewall to filter data going to and from clients outside the domain of the LAN. Data entering the LAN domain is usually expressed as passing from the “outside,” usually the Internet, through the firewall to the “inside” where the LAN's entities exist.
There are recognized problems with current firewall technology. Often legitimate data is not able to pass through a firewall due to one or more particular policies that are enforced by the firewall. For example, one problem occurs when two network devices are in a communication session. In one scenario, a device A is exchanging data in the form of messages with a device B. The device A is inside the firewall, and the device B is outside. The firewall recognizes device A as the device sending legitimate messages, and has permission under its policies to send a message to device B. However, the firewall doesn't recognize that the device B has a right to send messages from the outside through the firewall to the device A.
In a restrictive firewall, the firewall may only allow the device A to send messages out to the device B, and will only allow messages from the device B if, and only if, the device A has first sent a message to the device B, and/or only if the device B has been pre-configured in the firewall's policies to have the authority to communication with the device A or other entities inside the firewall. The device B cannot initiate a communication to the device A through the firewall because the firewall is not configured to expect or allow a message from the device B to the device A.
Another problem arises when the device B does not have the information that the device A requires, and the device B must employ other devices to obtain the information that the device A needs. The current solutions are burdensome and require the subsequent devices to retrace their communication path with the device B in order to provide the answer to the device B, which will then send the answer to the device A. Frequently, the subsequent parties don't trust the device B to convey the message to the device A. For example, if the device A requests sensitive company personnel information from the device B, the device B may have to contract a personnel server P to retrieve the information. However, device B may not be authorized to receive the personnel information from server P. In that case, the personnel server P may only be able to send the information directly to the device A as the requester. Given that the original session was between device A and device B, the firewall's policies may not allow a third device that was not a party to the original communication to send the information to the device A. To the firewall, the attempted communication from the server P to the device A may appear unsolicited, and may be disallowed by the firewall. The scenario immediately above is generally referred to as the “delegation” problem, where one device attempts to delegate a request to a third party device.
In even more complex delegations, the request from the device A may be routed through several third parties. Schematically, the scenario may appear as follows:A->∥B->C-> . . . ->RIf device R tries to send a reply directly to the device A, the restrictive firewall may block the reply because it does not have a record of the device A sending a message to the device R. This problem has special significance in scenarios where the device R is the only trusted source for the information, or when none of the intermediary devices are allowed to obtain the information due to security or privacy concerns.
One known solution is for the device R to send a message to the device B, so that the device B may send a message to the device A that the device R has the requested information. The device A may subsequently contact the device R, requesting that the device R provide the information. However, the firewall may not be configured to receive information from the device R, and it would be burdensome to require a re-configuration of the firewall every time a new third party device is found to contain the requested information.
Another known solution involves reconfiguring Internet protocol (IP) addresses using Internet protocol security (IPSec). IPSec is a set of protocols developed by the Internet engineering task force (IETF) to support secure exchange of packets at the IP layer. IPsec has been deployed widely to implement virtual private networks (VPNs). IPsec supports two encryption modes: transport and tunnel. Transport mode encrypts only the data portion (payload) of each packet, but leaves the header untouched. The more secure tunnel mode encrypts both the header and the payload. On the receiving side, an IPSec-compliant device decrypts each packet.
For IPsec to work, the sending and receiving devices must share a public key. This is accomplished through a protocol known as Internet Security Association and Key Management Protocol/Oakley (ISAKMP/Oakley), which allows the receiver to obtain a public key and authenticate the sender using digital certificates.
The IPSec solution suffers from a problem similar to that associated with using restrictive firewalls. The IPSec solution requires extensive configuration to facilitate communication between all devices participating in a communication, except that IPSec requires configuration on each device apart from just the firewall itself.
Another known solution uses host identify protocol (HIP). HIP provides a rapid exchange of device or host identities between two hosts. The exchange also establishes a pair of IPSec security associations (SA), to be used with IPsec. HIP protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks, and provides DoS and MitM protection for upper layer protocols, such as TCP and UDP. However, as with pure IPSec protocol, HIP also requires extensive configuration with each device involved in a communication before it can be used.
Another known solution uses cryptographically generated addresses (CGAs). CGAs are IP addresses where the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IP address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. CGA works without a certification authority or other security infrastructure.
However, just as is the case with IPSec and HIP protocols, CGA protocol also requires extensive configuration of each device involved in a communication before it can be used. Due to this requirement, none of these solutions, or solutions like them, solve the problem of allowing a third party device R that was previously unknown to the device A inside the firewall to provide information, originally requested from B, to the device A directly.